Design and Initial python api #16
Conversation
|
|
||
| ## Overview | ||
|
|
||
| This document outlines the design for integrating Python's `sys.monitoring` API with the `runtime_tracing` format. The goal is to produce CodeTracer-compatible traces for Python programs without modifying the interpreter. |
There was a problem hiding this comment.
i didn't know much about sys.monitoring before , it sounded a bit like a profile-only api, collecting statistical data, but not every event, but i am probably wrong
There was a problem hiding this comment.
yes, it seems it's indeed a newer alternative to settrace
There was a problem hiding this comment.
It is a new API which can be used for debugging as well
-------- >8 -------- >8 -------- 8< -------- 8< -------- # Everything below the snippet mark will be ignored # # Content diff of this revision:
tzanko-matev
force-pushed
the
initial-python-api
branch
from
df2942c to
d2b0390
Compare
design-docs/design-001.md
Outdated
| ```rs | ||
| pub fn on_line(frame: *mut PyFrameObject, lineno: u32); | ||
| ``` | ||
| - **INSTRUCTION** – Optionally emit a fine-grained `Event` containing the opcode name for detailed traces. |
There was a problem hiding this comment.
we have Asm events for those cases indeed
design-docs/design-001.md
Outdated
| ```rs | ||
| pub fn on_jump(frame: *mut PyFrameObject, target: u32); | ||
| ``` | ||
| - **BRANCH** – Record an `Event` with branch outcome (taken or not) to aid coverage analysis. |
There was a problem hiding this comment.
currently this is not part of the trace, but based on AST treesitter analysis matching the taken lines with if and similar; maybe we can support something more fine-grained optionally ? if useful
There was a problem hiding this comment.
Ok, I'll update the spec. There's probably no need to implement this
design-docs/design-001.md
Outdated
| ### C API Boundary | ||
| - **C_RETURN** – On returning from a C function, emit a `Return` event tagged as foreign and include result summary. | ||
| ```rs | ||
| pub fn on_c_return(func: *mut PyObject, result: *mut PyObject); |
There was a problem hiding this comment.
we can integrate this with rr backend in the future somehow or with a custom db-backend based C recording(??) but for now seems reasonable
design-docs/design-001.md: Fix design of MonitoringEvents The values of the events should come from sys.monitoring and not be set in the Rust code, because we risk inconsistencies this way Signed-off-by: Tzanko Matev <[email protected]> design-docs/design-001.md: Fix event callback types and get rid of PyFrameObject PyFrameObject is not part of sys.monitroing API Signed-off-by: Tzanko Matev <[email protected]> design-docs/design-001.md: CodeObject access Since PyO3 doesn't provide access to PyCodeObject internals we need an alternative way to access them Signed-off-by: Tzanko Matev <[email protected]> design-docs/design-001.md: We'll ignore BRANCH events initially Signed-off-by: Tzanko Matev <[email protected]>
tzanko-matev
force-pushed
the
initial-python-api
branch
from
d2b0390 to
4876258
Compare
No description provided.